На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).

При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:

В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.

То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.

Также нужно убедиться, что ваш хост не использует политику питания High performance power management policy, которая отключает Turbo Boost. Вместо этого используйте политику Balanced, которая включена по умолчанию.

Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.

Вот эти дашборды:

• Grafana vSphere Overview Dashboard – 8159
• Grafana vSphere Datastore Dashboard – 8162
• Grafana vSphere Hosts Dashboard – 8165
• Grafana vSphere VMs Dashboard – 8168

Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:

• Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - фреймворк, который используется для визуализации метрик из базы.

О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:

1. vSphere Overview Dashboard.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.

Лайв-демо такого дэшборда доступно по этой ссылке.

2. vSphere Datastore Dashboard.

Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

3. vSphere Hosts Dashboard.

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

Лайв-демо такого дэшборда доступно по этой ссылке.

4. vSphere VMs Dashboard.

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

5. vSphere Hosts IPMI dashboard.

Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.

Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:

• Grafana Dashboard for Veeam Availability Console - SP Overview
• Grafana Dashboard for Veeam Availability Console - Tenant Overview
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0 - Security and Performance
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v4

Ну в заключение, стоит отметить еще один дэшборд автора - Microsoft Azure Storage.

Бывает так, что в вашей виртуальной инфраструктуре есть несколько серверов VMware vCenter, объединенных с помощью режима Linked Mode. Потом, например, вы теряете один из серверов vCenter. При этом после запуска консоли vSphere Client или vSphere Web Client на мастер-сервере vCenter вы видите предупреждение об отсутствующем сервере vCenter в объединенной конфигурации:

Could not connect to one or more vCenter Server Systems

Чтобы убрать это оповещение и привести конфигурацию в порядок, надо залогиниться на главный сервер vCenter и выполнить там следующую команду:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost<br>

https://vcenter-1.home.lab:443/lookupservice/sdk<br>

Если вывод будет таким, значит у вас нет внешнего Platform Services Controller (PSC), можно продолжать исполнять команды локально. Выводим список всех узлов vCenter:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list

Enter password for administrator@sso-1.local:

Node: vcenter-1.home.lab

Type: PSC

Site: First-local

Partner #1: ldap://vc_old.home.lab



Node: vc_old.home.lab

Type: PSC

Site: First-local

Partner #1: ldap://vcenter-1.home.lab

Здесь мы видим, что у нас есть два узла в Linked-конфигурации. Чтобы удалить узел vc_old, нужно выполнить следующую команду:

cmsso-util unregister –node-pnid vc_old.home.lab –username administrator@sso-1.local

Результат будет примерно таким:

root@vcenter-1 [ ~ ]# cmsso-util unregister --node-pnid vc_old.home.lab --username administrator@sso-1.local

Password:

Solution users, computer account and service endpoints will be unregistered

2020-02-10T13:02:41.359Z Running command: ['/usr/lib/vmware-vmafd/bin/dir-cli', 'service', 'list', '--login', 'administrator@sso-1.local']

2020-02-10T13:02:41.399Z Done running command

Stopping all the services ...

All services stopped.

Starting all the services ...

Started all the services.

Success

Проверяем, что старый vCenter удален из списка:

root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list

Enter password for administrator@sso-1.local:

Node: vcenter-1.home.lab

Type: PSC

Site: First-local

После этого предупреждение о невозможности подключиться к серверу vCenter исчезнет из vSphere Client.

Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.

На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.

В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.

Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:

// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);

А вот так можно вывести список всех тэгов для конкретной виртуальной машины:

$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)

Больше интересных практических приемов работы с тэгами вы найдете в приложении к документу VMware vSphere 6.7 Tagging Best Practices.

Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:

В консоли браузера Chrome можно увидеть вот такую ошибку:

Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID

Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:

1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке: 

https://<current-hostname>/ui/#/host/networking/netstacks/defaultTcpipStack

2. Изменяем настройки хоста.

Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.

3. Идем по ssh на хост ESXi и выполняем там следующие команды:

cd /etc/vmware/ssl
/sbin/generate-certificates

Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.

4. Перезапускаем службу хоста ESXi:

/etc/init.d/hostd restart

После этого vSphere Client через Chrome 80 должен работать без проблем.

На днях компания VMware сделала анонс о грядущих изменениях в лицензировании платформы виртуализации VMware vSphere. Теперь понятие "лицензия на CPU" будет включать в себя процессоры, которые содержат до 32 физических ядер.

Если в процессоре больше ядер, то квантоваться они будут по 32 штуки - то есть, если в физическом CPU 64 ядра, то вам потребуется 2 лицензии VMware vSphere (2x32). Надо понимать, что речь идет о физических ядрах процессоров, а не о логических, доступных через Hyper-threading.

Процессоры с таким количеством ядер уже не за горами - например, AMD анонсировала процессор Ryzen 9 3990X с 64 ядрами, который будет стоить $4 000 (его обещают выпустить уже 7 февраля). Intel уже продает процессор Xeon Platinum 8280 с 28 ядрами на борту, но скоро в соревновании с AMD неизбежно надо будет делать больше ядер - так что изменения в лицензировании vSphere уже скоро станут вполне актуальны.

Наглядно новую схему лицензирования процессоров можно представить так:

Данные изменения вступят в силу 2 апреля 2020 года, но до 30 апреля действует grace period - то есть до этой даты вы сможете купить и лицензировать хосты VMware ESXi по старым правилам (очевидно, что VMware потребует доказательства приобретения и самих серверов до этой даты). Поэтому если до этого времени вдруг у ваших процессоров окажется очень много ядер - самое время будет приобрести лицензии VMware vSphere впрок.

На днях компания Intel опубликовала руководство по безопасности Security Advisory INTEL-SA-00329, в котором описаны новые обнаруженные уязвимости в CPU, названные L1D Eviction Sampling (она же "CacheOut") и Vector Register Sampling. Прежде всего, надо отметить, что обе этих уязвимости свежие, а значит исправления для них пока не выпущено.

Соответственно, VMware также не может выпустить апдейт, пока нет обновления микрокода CPU от Intel. Когда Intel сделает это, VMware сразу выпустит патч, накатив который на VMware vSphere вы избавитесь от этих потенциальных уязвимостей.

Основная позиция VMware по вопросу этих уязвимостей приведена в статье KB 76949 - VMware response to Vector Register Sampling (CVE-2020-0548) and L1D Eviction Sampling (CVE-2020-0549) speculation execution vulnerabilities in Intel processors. Соответственно, первым делом надо подписаться на обновление этой статьи (также неплохо бы подписаться на список рассылки VMware Security Advisory).

Давайте посмотрим, что это за уязвимости:

• Vector Register Sampling (CVE-2020-0548). Эта уязвимость является пережитком бага, найденного в подсистеме безопасности в ноябре прошлого года. Она связана с атаками типа side-channel, о которых мы писали вот тут. В рамках данной атаки можно использовать механизм Transactional Synchronization Extensions (TSX), представленный в процессорах Cascade Lake. О прошлой подобной уязвимости можно почитать вот тут. А список подверженных уязвимости процессоров Intel можно найти тут.
• L1D Eviction Sampling (CVE-2020-0549). Эта уязвимость (ее также называют CacheOut) позволяет злоумышленнику, имеющему доступ к гостевой ОС, получить доступ к данным из памяти других виртуальных машин. Более подробно об уязвимостях данного типа можно почитать на специальном веб-сайте. Также вот тут находится список уязвимых процессоров.

Следите за обновлениями VMware, патчи будут доступны сразу, как только Intel обновит микрокод процессоров. Достаточно будет просто накатить обновления vSphere - и они пофиксят уязвимости CPU.

На сайте проекта VMware Labs появилась новая версия мобильного клиента для управления платформой VMware vSphereс мобильного телефона - vSphere Mobile Client 1.9.1 (а немногим ранее вышла версия 1.9). Напомним, что прошлая версия клиента vSphere Mobile Client 1.6 была выпущена в октябре прошлого года.

Давайте посмотрим, что нового появилось в мобильном клиенте за последнее время:

• Возможность сохранить информацию о доступе к vCenter Server (адрес сервера и имя пользователя).
• Возможность использовать распознавание FaceId или доступ по отпечатку пальца для логина на сервер vCenter.
• Добавлено быстрое действие выключения хоста ESXi.
• Улучшена совместимость с движком автозаполнения в полях ввода логина.
• Исправлены мелкие баги прошлых версий.

Скачать обновленный vSphere Mobile Client 1.9.1 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.

В целом, инициатива эта позитивная - она согласуется с оповещением безопасности CVE-2017-8563, которое говорит о том, что незащищенная коммуникация LDAP может быть скомпрометирована. Поэтому, начиная с марта, любая LDAP-коммуникация, которая не использует TLS, потенциально может быть отвергнута Windows-системой. Почитайте, кстати, об этой суете на Reddit.

Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.

Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).

Проверить текущую интеграцию с LDAP в vCenter можно в разделе Configuration -> Identity Sources:

Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.

После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:

Invalid Credentials

При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:

Check the network settings to make sure you have network access to the identity source

Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.

Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:

• 2020 Microsoft LDAP channel binding and LDAP signing requirement for Windows
• ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
• Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure
• How to enable LDAP signing in Windows Server 2008
• CVE-2017-8563 | Windows Elevation of Privilege Vulnerability

Документ о настройке LDAP Signing в Windows Server 2008 говорит, что вам надо изменить групповую политику "Default Domain Policy" (для домена), а также "Default Domain Controllers Policy" (для контроллеров домена), после чего дождаться ее обновления или обновить ее командой gpupdate /force.

Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).

Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:

Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:

После этого вы должны увидеть ошибку "Error 0x2028 A more secure authentication method is required for this server", которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:

Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.

О настройке сервера vCenter для LDAPS рассказано вот тут. Единственное, что вам потребуется - это добавить рутовый сертификат для сервера vCenter, который можно вывести следующей командой (если под Windows надо будет поставить Open SSL, под Linux утилита уже встроена):

echo | openssl s_client -showcerts -connect <FQDN>:636

Далее скопируйте все данные между "—–BEGIN CERTIFICATE—" и "—–END CERTIFICATE—–", после чего сохраните это в текстовый файл.

Никакой срочности до марта нет, поэтому не нужно суетиться и обновлять все Identity Sources, но разрабатывать план по переходу на LDAPS и тестировать его нужно уже сейчас. Будет неприятно, если пользователи неожиданно столкнутся с проблемой аутентификации. И да, откладывать обновления Windows не вариант - это единственный способ своевременно закрывать дырки в сфере информационной безопасности для вашей компании.

Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.

1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.

Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).

В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.

2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).

Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.

Также будет не лишним выполнить тест сети управления - опция Test Management Network. Ошибки, возникающие при этом, помогут понять, что случилось:

3. Проверьте, что со стороны vCenter Server у вас есть соединение с хостом ESXi - как по IP, так и по FQDN.

Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:

4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.

Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.

Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:

В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.

Ваша задача - обеспечить коммуникацию хоста ESXi с сервером vCenter по порту 902 (TCP/UDP):

Проверить коммуникацию по порту 902 можно с помощью Telnet.

Также тут вам могут помочь следующие статьи базы знаний VMware:

• Verifying the vCenter Server Managed IP Address (1008030)  
• ESXi 5.0 hosts are marked as Not Responding 60 seconds after being added to vCenter Server (2020100)
• ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630) 
• ESX/ESXi host keeps disconnecting and reconnecting when heartbeats are not received by vCenter Server (1005757)

Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.

5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.

Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:

Потом просто добавьте хост ESXi в окружение vCenter снова.

6. Если ничего из этого не помогло - время заглянуть в логи.

В первую очередь надо посмотреть в лог агента vpxa (/var/log/vpxa.log), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:

[2007-07-28 17:57:25.416 'Memory checker' 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 'Memory checker' 3076453280 info] Resource checker stopped.

Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd (/var/log/vmware/hostd.log), как описано в KB 1002849. Например, там может быть вот такая ошибка:

2014-06-27T19:57:41.000Z [282DFB70 info 'Vimsvc.ha-eventmgr'] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive

Ошибки могут вызывать разные причины, но наиболее частая из них - нехватка ресурсов для сервиса hostd.

7. Последнее, но не менее важное - проверить, нет ли проблем с хранилищем.

Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):

Вывод

Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.

Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.

На днях компания VMware выпустила очередное обновление своей утилиты для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные) - Cross vCenter Workload Migration Utility 3.1. Напомним, что версия 3.0 этого средства выходила на VMware Labs в ноябре прошлого года.

Давайте посмотрим на новые возможности утилиты:

• Поддержка конвертации форматов диска между Thick (Lazy Zeroed), Thick (Eager Zeroed) и Thin provisioning.
• Поддержка шаблона переименования виртуальной машины при операциях клонирования.

Также появилась парочка багофиксов:

• Устранена ошибка дубликата выбранной сети при пакетной миграции ВМ.
• Исправлена ошибка запуска, когда указан новый домашний vCenter в качестве аргумента командной строки.

Напомним, что утилитой можно пользоваться через плагин в составе vSphere Client с интерфейсом на базе технологии HTML5, так и в отдельном графическом интерфейсе.

Скачать Cross vCenter Workload Migration Utility 3.1 можно по этой ссылке.

В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.

Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.

Собственно, сам постер:

Второй интересный постер - это vRealize Network Insight Search Poster for Kubernetes. Он позволит вам найти объекты нативной инфраструктуры Kubernetes или развернутой на платформах VMware PKS или OpenShift.

Итого все постеры по функциям поиска в решении vRNI вы можете скачать по этим ссылкам:

• Kubernetes Search Poster
• SD-WAN & VeloCloud Search Poster
• NSX for vSphere Search Poster
• Network Flow Search Poster
• Virtual Machine Search Poster

На сайте проекта VMware Labs появилась действительно интересная новинка - утилита vSphere Software Asset Management (vSAM). С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии, проще говоря, ассеты.

Утилита забирает все данные по API и генерирует отчет об использовании лицензий виртуальной инфраструктуре в формате PDF, который могут использовать администраторы, менеджеры и консультанты для целей отчетности, планирования и любых других.

Сама утилита vSAM представляет собой легковесное Java-приложение, которое может работать под Windows, Linux или Mac OS. Давайте посмотрим на его возможности:

• Поддержка кластера хостов ESXi под управлением vCenter Server, а также отдельных серверов ESXi с версиями vSphere 5.5, 6.x или более новыми.
• Генерация комплексных отчетов в следующих категориях:
  • Высокоуровневая информация об инсталляции
  • Отчет о компонентах (отдельные ESXi или кластер серверов с vCenter)
  • Высокоуровневый отчет об использовании лицензионных ключей
• Генерация рекомендаций в следующих сферах:
  • Оповещение об использовании триальной лицензии
  • Срок лицензии:
    • Оповещение об истечении лицензии через 90 дней
    • Алерты об истекших лицензиях
  • Емкость доступных лицензий
    • Оповещение об использовании лицензий выше заданного порога
    • Оповещение о нехватке лицензий
    • Алерт о превышении лицензионных лимитов
  • Жизненный цикл продуктов
    • Информация по вступлении в фазу End of General Support info
    • Оповещение за 90 дней для EoGS
    • Нотификация о неподдерживаемых больше продуктах
  • Защита чувствительной информации за счет:
    • Сбор данных только для задачи Software Asset Management
    • Маскирование чувствительной информации в отчете
    • Поддержка шифрования файла с сырыми данными
  • Поддержка объединения нескольких отчетов в один
  • Поддержка английского и китайского языков
  • Поддержка кастомизации отчетов

Вот примеры сгенерированных отчетов:

Скачать утилиту VMware vSphere Software Asset Management Tool можно по этой ссылке.

Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях было выпущено небольшое обновление архитектуры VCF 3.9.1, где появилось несколько небольших новых возможностей.

Главное обновление - это новый Bill of Materials (BoM) для последних версий продуктов (включая апдейты 2020 года):

Остальные новые возможности включают в себя:

• Функция Application Virtual Networks (AVN) - она позволяет решению vRealize Suite быть развернутым в сетях NSX overlay networks. AVN, которые являются стандартом по умолчанию, начиная с этой версии архитектуры VCF, предоставляют преимущества портируемости и быстрого восстановления после запланированного простоя или в случае аварии. Чтобы узнать больше об этих сетях и перевести компоненты vRealize Suite на эту технологию почитайте вот эту статью.
• Поддержка API для нескольких физических сетевых адаптеров и распределенных коммутаторов (vSphere Distributed switches). Теперь API поддерживает до трех vDS и до 6 физических NIC, что дает возможность применения API в высокопроизводительных средах с большим числом адаптеров и виртуальных коммутаторов (например, физическое разделение типов трафика).
• Улучшения Cloud Builder - обновленный графический интерфейс включает в себя несколько улучшений рабочих процессов, а также показывает в отчетах детали задач, которые были выполнены во время развертывания.
• Улучшения Developer Center - теперь можно получить доступ к Cloud Foundation API и примерам кода из дэшборда SDDC Manager.

Более подробная информация об улучшениях VMware Cloud Foundation 3.9.1 приведена в Release Notes.

Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.

Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:

• Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
• На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
• Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
• Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
• Множество исправлений ошибок и улучшений движка анализа.

Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.

Интересное наблюдение от коллеги с блога ivobeerens.nl - оказывается драйверы pvscsi и vmxnet3, входящие в состав пакета VMware Tools, накатываются в гостевую ОС машин VMware vSphere через службу обновлений Windows Update:

В версии VMware Tools 10.3.10 (или выше) это работает для ОС Windows Server 2016 и Windows Server 2019.

Таким образом, указанные драйверы обновляются как часть процесса обновления Windows, что, в свою очередь, сокращает число требуемых перезагрузок во время обновлений.

Многие крупные организации до сих пор используют платформу VMware vSphere 6.0 в качестве основы своей ИТ-инфраструктуры. Это обусловлено трудностями планирования апгрейда для большого парка серверов, лицензионной спецификой и в целом нежеланием трогать то, что работает хорошо.

Но надо обязательно напомнить, что 12 марта 2020 года, согласно плану, указанному в документе VMware Lifecycle Product Matrix, платформе vSphere 6.0 и гипервизору ESXi 6.0 наступает End of Life (EoL), а в терминологии VMware - End of General Support:

Согласно политикам VMware Support Policies, статус End of General Support для продуктов VMware означает, что для них перестают выпускаться существенные обновления и патчи. Поддержка по телефону также заканчивается, а с точки зрения апдейтов выпускаются только самые критичные обновления, закрывающие дырки безопасности и самые серьезные баги. То есть продукт входит в фазу Technical Guidance:

В связи с этим, пользователям vSphere 6.0 настоятельно рекомендуется провести обновление до версий vSphere 6.5 или 6.7 к этому времени. Кстати, надо отметить, что у обеих версий дата перехода в фазу Technical Guidance одна и та же - 15 ноября 2021 года:

Совместимость вашей платформы VMware vSphere 6.0, а точнее ее компонентов ESXi 6.0 и vCenter 6.0, с другими продуктами VMware вы можете проверить на специальной странице VMware Product Interoperability Matrices:

Не все администраторы виртуальной инфраструктуры VMware vSphere в курсе, что в этой платформе доступен удобный инструмент, который позволяет сгенерировать PowerCLI-сценарий из последовательности действий, которые выполняет администратор в интерфейсе vSphere Client.

Эта функция называется Code Capture, и появилась она весной прошлого года в обновлении платформы VMware vSphere 6.7 Update 2, о которой мы писали вот тут. Этот механизм VMware тестировала еще в далеком 2009 году, тогда он назывался Project Onyx.

Чтобы получить доступ к этой фиче, нужно в меню vSphere Client выбрать пункт Developer Center, где есть переключатель Enable Code Capture:

После того, как вы включите Code Capture, в верхнем тулбаре клиента появится красная кнопка записи:

Например, можно нажать на нее и, как показано на скриншоте выше, запустить клонирование виртуальной машины, а затем включить созданную ВМ.

После того, как вы запишете сессию, можно нажать кнопку Stop Recording, после чего будет сгенерирован PowerCLI-сценарий, с помощью которого можно автоматизировать развертывание новой машины:

Полученный скрипт можно скопировать или скачать для последующего его изменения уже в собственном редакторе. Надо отметить, что поскольку сценарий генерируется автоматически - он получается далеко не самым оптимальным с точки зрения структуры и времени работы. Поэтому если вы умеете разрабатывать сценарии на PowerCLI, то лучше делать их вручную с нуля. С другой стороны, не все действия в клиенте понятно, как автоматизировать, и какие командлеты использовать - поэтому Code Capture определенно может помочь подобрать нужные.

Если хочется сделать сценарий по-новой, то можно нажать кнопку "Clear and start another" - это удалит прошлый скрипт (не забудьте сохранить его, если он нужен) и начнет новую сессию записи.

Чтобы отключить функцию code capture для всех пользователей, нужно добавить строчку "codecapture.disabled=true" в файл конфигурации клиента vSphere Client (надо будет его перезапустить): /etc/vmware/vsphere-client/vsphere-client/webclient.properties.

Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":

Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).

Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.

Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.

Под конец года компания VMware выпустила очередной полезный администраторам VMware vSphere постер - VMware PowerCLI 11 Storage Module Reference Poster for vSAN. В постере приведено несколько полезных командлетов для последней версии PowerCLI, которые позволяют управлять хранилищами VMware vSAN с помощью модуля Storage.

С левой стороны перечислены все командлеты данного модуля, разбитые по группам, а справа приведены примеры использования различных команд и простых сценариев для выполнения типовых задач. Например, показано как узнать емкость датастора vSAN, установить VIB-пакет на хост vSAN или включить функцию vSAN Encryption в кластере.

Скачать постер VMware PowerCLI 11 Storage Module Reference Poster for vSAN можно по этой ссылке.

В блоге о производительности VMware появился интересный пост о том, как технология CPU Hot Add влияет на производительность операций в виртуальной машине. Как вы знаете, возможности Hot Add в VMware vSphere позволяют добавлять аппаратное обеспечение в виртуальную машину без необходимости ее выключения. В частности, CPU Hot Add позволяет добавить vCPU в запущенную ВМ таким образом, чтобы поддерживающая эту возможность гостевая ОС сразу приняла этот процессор в работу.

Между тем, согласно статье KB 2040375, функция Hot Add существенно влияет на производительность гостевой ОС, поскольку механизм горячего добавления узлов отключает функцию vNUMA. Напомним, что этот механизм включается при количестве vCPU большем 8 для одной виртуальной машины и позволяет самым оптимальным образом отображать физическую архитектуру сервера на топологию NUMA-узлов виртуальной машины (по количеству и размеру). Это приводит к тому, что CPU и память стараются взаимодействовать друг с другом в рамках одного NUMA-узла, что приводит к наименьшим задержкам при выполнении операций.

В VMware для измерения численных показателей потерь производительности при включении Hot Add решили взять бенчмарк DVD Store 3 (DS3), который используется для тестирования рабочих нагрузок в транзакционных базах данных (в частности нагрузок, например, интернет-магазинов). В качестве референсной базы данных использовалась БД размером 300 ГБ, а доступ к ней через драйвер DS3 производился из виртуальной машины с 20 vCPU и 32 ГБ RAM на борту.

Напомним, что для ВМ функции Hot Add включаются и отключаются в разделе Virtual Hardware > CPU > CPU Hot Plug, где есть чекбокс Enable CPU Hot Add.

При 28 vCPU в виртуальной машине и выключенном Hot Add консоль SQL Server Management Studio видит 2 NUMA-узла:

При включенном - только один NUMA-узел:

Далее были запущены стандартные тесты для обеих конфигураций с постепенным увеличением числа потоков для воркеров (threads), где главным критерием производительности было число операций в минуту (orders per minute, OPM). В итоге получилась вот такая картина:

Результат - включение Hot Add снизило производительность на 2-8% в зависимости от числа потоков. Поэтому включать Hot Add для виртуальной машины нужно только тогда, когда вам точно нужно именно горячее добавление vCPU или vRAM для этой ВМ.

На сайте проекта VMware Labs появилась еще одна интересная утилита - vCenter Plugin for vRealize Network Insight. С помощью данного плагина для управляющего сервера vCenter можно получить всю необходимую информацию от решения VMware vRealize Network Insight (vRNI) в консоль vSphere Client в виде отдельного раздела.

Это все позволяет администраторам виртуальной инфраструктуры VMware vSphere видеть информацию о сетевом взаимодействии в виртуальном датацентре и потоках виртуальных машин сразу в клиенте vSphere, без необходимости постоянно переключаться между двумя консолями:

Возможности плагина:

• Верхнеуровневый обзор активности vCenter: виртуальные машины, миграции vMotion и снапшоты.
• Отображение сетевой информации напрямую в vCenter:
  • Представление поведения внутреннего сетевого трафика east-west, сколько трафика расходуется.
  • Нарушение жизнедеятельности (хэлсчеков) для vCenter и прикрепленных к нему NSX-окружений.
  • Самые использующие сеть виртуальные машины, сгруппированные по именам, кластерам, сетям L2, подсетям, группам безопасности, паре источник-назначение, сети источник-назначение, IP-адресам источника и назначения.
  • Самые используемые сети.
  • Новые виртуальные машины, использующие интернет-трафик (полезно для обнаружения подозрительных активностей).
  • Топ-5 хостов и сетей, в которых наблюдается наибольшая потеря пакетов.
• Ссылка на консоль vRealize Network Insight, показывающие исходные данные и позволяющие глубже провалиться в детали. Можно применять фильтры, экспортировать данные и другое.
• Возможность настройки vCenter как источника данных и настройка NetFlow на доступных распределенных коммутаторах vSphere Distributed Switches.

Скачать vCenter Plugin for vRealize Network Insight можно по этой ссылке. Инструкции по развертыванию доступны тут.

В сентябре этого года мы писали о новой версии пакета VMware Tools 11 для гостевых ОС виртуальных машин на платформе VMware vSphere. Одной из новых возможностей обновленной версии тулзов был читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Недавно Вильям Ламм пояснил, как именно может работать этот механизм, который дает возможность получить данные о процессах в гостевой ОС и их свойствах.

Для начала начала надо включить Application Discovery в гостевой ОС с помощью утилиты VMwareToolbox. По умолчанию этот механизм отключен, чтобы не создавать дополнительную нагрузку на виртуальную машину.

Для включения нужно выполнить следующую команду:

• Windows: VMwareToolboxCmd.exe config set appinfo enabled true
• Linux: vmware-toolbox-cmd config set appinfo enabled true

Выглядит это таким образом:

После того, как сбор данных включен, они будут обновляться каждые 30 минут - то есть эта функция не предназначена для мониторинга процессов в реальном времени, а скорее для сбора информации об имеющихся в ВМ приложениях и их свойствах. Чтобы изменить интервал обновления, используйте следующие команды:

• Linux: vmware-toolbox-cmd config set appinfo poll-interval <new value in seconds>
• Windows: VMwareToolboxCmd.exe config set appinfo poll-interval <new value in seconds>

Например, AppInfo может собирать информацию о версии всех приложений, что может оказаться полезным при автоматизированном поиске устаревших версий приложений с помощью сценариев.

Вильям написал PowerCLI-скрипт Get-VMApplicationInfo.ps1, который принимает на вход виртуальную машину, а на выходе выдает информацию о процессах гостевой ОС с меткой времени сбора данных.

Результат работы сценария можно вывести в CSV-файл или в JSON-массив.

Ну а дальше уже можно фантазировать, для чего подобная информация может пригодиться именно в вашей виртуальной инфраструктуре.

Осенью прошлого года мы писали об официальных стенсилах VMware для Visio, которые помогают инженерам и техническим писателям делать схемы, диаграммы и отчеты для документирования виртуальной инфраструктуры.

За прошедший год эти стенсилы и шаблоны были пару раз обновлены, поэтому рекомендуется скачать и использовать их актуальные версии. Давайте посмотрим, что нового появилось за год:

• Были добавлены примеры диаграмм с низкой и средней сложностью.
• Очень существенно были обновлены иконки продуктов и фичей.
• Пофикшены проблемы с файлом иконок vmware-sddc-icons.vssx и добавлен новый шаблон виртуального датацентра vmware-sddc-template.vsdx.

Напомним рекомендации насчет этих иконок и стенсилов в целом:

• Используйте шрифт Arial Regular.
• Сначала создавайте текстовые блоки, чтобы понять, что дизайн вписывается в максимальный размер элементов по ширине.
• Не используйте шрифт менее 11 пунктов.
• Не масштабируйте фигуры и иконки - это может привести к их искажениям.
• Не используйте другой формат страницы, это тоже может вызвать сбой в визуализации.

Скачать официальные VMware Visio Stencils 2019 можно по этой ссылке.

Вильям Ламм написал интересную статью про вывод информации обо всех доступных событиях на сервере VMware vCenter. Недавно мы писали о решении vCenter Event Broker Appliance (VEBA), которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Так вот, администраторы, использующие VEBA, часто задают вопрос о том, как найти конкретное событие vCenter и его ID в целях автоматизации операций. Также иногда это необходимо для использования с vSphere API. Для этого Вильям написал PowerCLI скрипт, который экспортирует список всех происходивших событий vCenter в CSV-файл, где в отдельных колонках приведены EventId, EventType (может быть Standard, EventEx или ExtendedEvent) и EventDescription:

$vcenterVersion = ($global:DefaultVIServer.ExtensionData.Content.About.ApiVersion)

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$results = @()
foreach ($event in $eventMgr.Description.EventInfo) {
    if($event.key -eq "EventEx" -or $event.key -eq "ExtendedEvent") {
        $eventId = ($event.FullFormat.toString()) -replace "\|.*",""
        $eventType = $event.key
    } else {
        $eventId = $event.key
        $eventType = "Standard"
    }
    $eventDescription = $event.Description

    $tmp = [PSCustomObject] @{
        EventId = $eventId;
        EventType = $eventType;
        EventDescription = $($eventDescription.Replace("<","").Replace(">",""));
    }

    $results += $tmp
}

Write-Host "Number of Events: $($results.count)"
$results | Sort-Object -Property EventId | ConvertTo-Csv | Out-File -FilePath vcenter-$vcenterVersion-events.csv

Пример результатов работы данного сценария как для VMware vCenter 6.7 Update 3, так и для облачной среды VMware Cloud on AWS 1.8, можно найти в репозитории по этой ссылке: https://github.com/lamw/vcenter-event-mapping.

Также можно добавить в поток событий VMware vCenter и свое собственное событие. Можно сэмулировать как стандартное событие vCenter для тестирования срабатывания алармов vCenter, так и сделать кастомное.

Вот пример сценария, который генерирует такое событие в vCenter:

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$customEvent = New-Object VMware.Vim.EventEx
$customEvent.eventTypeId = "vGhettoWelcomeEvent"
$customEvent.message = "Hello from virtuallyGhetto"
$customEvent.ChainId = "0"
$customEvent.Key = "0"
$customEvent.CreatedTime = $(Get-Date -Format g)
$customEvent.UserName = "vGhetto-Bot"

$eventMgr.postEvent($customEvent,$null)

Это событие мы увидим в консоли VMware vCenter:

На скриншоте видно, что в поле Description отображается не то, что было задано в свойствах события. Это связано с тем, что за отображение этого поля отвечает другая подсистема. Чтобы это поле корректно отображалось для кастомных событий нужно зарегистрировать кастомное расширение (custom extension), которое будет публиковать информацию о событии. Более подробную информацию об ExtensionManager, с помощью которого это можно сделать, можно посмотреть вот тут.

Для большинства ИТ-специалистов виртуализация ассоциируется с накладными расходами на ее содержание. Виртуальная машина имеет такие-то потери по CPU и столько-то издержки по оперативной памяти. Но иногда бывает и обратная ситуация - например, в статье про производительность контейнеров на платформе Project Pacific утверждается, что в виртуальных машинах они работают на 8% быстрее, чем на голом железе с Linux на борту.

Давайте посмотрим, почему это может быть так.

Сначала для тестирования взяли 2 идентичных аппаратных конфигурации (кластер из двух узлов), на одной из которых развернули гипервизор ESXi на платформе Project Pacific (там Kubernetes pods работают в виртуальных машинах), а на второй поставили Linux с Kubernetes pods (видимо, подразумевается Red Hat) с настройками из коробки, которые работают нативно:

VMware объясняет высокую производительность Project Pacific тем, что гипервизор воспринимает Pods как изолированные сущности, которые можно адресовать на CPU для наиболее подходящих локальных NUMA-узлов. Планировщик ESXi уже давно умеет эффективно работать с NUMA-узлами для vCPU ВМ, поэтому вполне логично ожидать здесь хороших результатов.

При настройке Kubernetes на Linux пользователь, с точки зрения выделения ресурсов CPU, оперирует логическими ядрами, которые дает технология hyperthreading, а при настройке виртуальных машин - физическими pCPU, то есть физическими ядрами процессора. Поэтому для чистоты эксперимента в тестах производительности VMware отключала hyperthreading.

Конфигурация каждого Pod выглядела так:

Всего было развернуто 10 Kubernetes pods, каждый из которых имел лимит по ресурсам 8 CPU и 42 ГБ RAM. Далее там был запущен один из Java-бенчмарков, целевым показателем которого была полоса пропускания (maximum throughput).

Результат оказался следующим:

Из графика видно, что кластер vSphere дал на 8% лучше результаты, чем нативный кластер Kubernetes на Linux.

Чтобы понять механику процесса, VMware замерила число попаданий в local DRAM (на уровне локального NUMA-домена) по сравнению с remote DRAM при условии промаха кэша в L3 процессора.

Для ESXi число таких попаданий составило 99,2%:

Это означает, что планировщик ESXi умеет размещать процессы ВМ таким образом, чтобы они могли получать более быстрый доступ к local DRAM.

Если же использовать привязку узлов к NUMA-доменам (Numactl-based pinning) в Linux, то результат работы нативных контейнеров выглядит лучше, чем таковой в виртуальных машинах:

Между тем, такая жесткая привязка узлов Kubernetes к NUMA-узлам оказывается непрактичной, когда требуется развертывать большое количество контейнеров, и возникает большая вероятность ошибок в конфигурациях.

Поэтому из коробки получается, что контейнеры Project Pacific работают лучше, чем на Linux-платформе в контексте использования ресурсов CPU.

Некоторое назад мы детально рассказывали о продукте VMware Project Pacific, который был анонсирован на конференции VMworld 2019 в Сан-Франциско. Это решение является частью семейства продуктов VMware Tanzu, разработанного специально для создания единой платформы для контейнеризованных приложений и виртуальных машин, которые сейчас очень часто совместно работают в инфраструктуре крупных предприятий.

Многие администраторы виртуальных инфраструктур в курсе про технологию NVMe (интерфейс Non-volatile Memory дисков SSD), которая была разработана для получения низких задержек и эффективного использования высокого параллелизма твердотельных накопителей. Такие устройства хоть и стоят дороже, но уже показывают свою эффективность за счет использования десятков тысяч очередей команд, что дает очень низкие задержки, требующиеся в таких сферах, как системы аналитики реального времени, онлайн-трейдинг и т.п.

К сожалению, протокол iSCSI (да и Fibre Channel тоже) разрабатывался тогда, когда инженеры еще не думали об архитектуре NVMe и высоком параллелизме, что привело к тому, что если использовать iSCSI для NVMe, использование таких хранилищ происходит неэффективно.

Главная причина - это одна очередь команд на одно устройство NVMe, которую может обслуживать iSCSI-протокол, весь смысл параллелизма теряется:

Вторая проблема - это то, что iSCSI использует процессор для диспетчеризации операций ввода-вывода, создавая дополнительную нагрузку на серверы, а также имеет некоторые сложности по перенаправлению потоков операций для нескольких контроллеров NVMe и устройств хранения на них.

Для этого и был придуман протокол NVMe over Fabrics (NVMe-oF), который не имеет таких ограничений, как iSCSI. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP.

Компания StarWind сделала свою реализацию данного протокола для продукта StarWind Virtual SAN, чтобы организовать максимально эффективное использование пространства хранения, организованного с помощью технологии NVMe. Об этом было объявлено еще осенью прошлого года. Он поддерживает 64 тысячи очередей, в каждой из которых, в свою очередь, может быть до 64 тысяч команд (в реальной жизни в одной очереди встречается до 512 команд).

Важный момент в реализации NVMe-oF - это применение технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы.

Также RDMA позволяет маппить несколько регионов памяти на одном NVMe-контроллере одновременно и организовать прямое общение типа точка-точка между инициаторами разных хостов (несколько Name Space IDs для одного региона) и этими регионами без нагрузки на CPU.

Такой подход, реализованный в продуктах StarWind, дает потрясающие результаты в плане производительности, о которых мы писали вот в этой статье. К этой статье можно еще добавить то, что реализация инициатора NVMe-oF на базе Windows-систем и таргета на базе Linux (который можно использовать в программно-аппаратных комплексах StarWind Hyperconverged Appliances, HCA) дала накладные издержки на реализацию всего 10 микросекунд по сравнению с цифрами, заявленными в даташитах производителя NVMe-устройств. Знающие люди поймут, насколько это мало.

Еще надо отметить, что бесплатный продукт StarWind NVMe-oF initiator - это единственная программная реализация инициатора NVMe-oF на сегодняшний день. В качестве таргета можно использовать решения Intel SPDK NVMe-oF Target и Linux NVMe-oF Target, что позволяет не зависеть жестко от решений StarWind.

Подробнее о StarWind NVMe-oF initiator можно узнать вот в этой статье. А загрузить его можно по этой ссылке.

На днях компания VMware зарелизила небольшие обновления компонентов платформы виртуализации vSphere 6.7 Update 3b. Release notes для vCenter 6.7 Update 3b можно посмотреть тут, а для ESXi 6.7 Update 3b - тут.

Нововведений особо никаких в новых апдейтах нет, в основном это фиксы подсистемы безопасности, которые регулярно выходят для всех компонентов VMware vSphere. Хотя один стоящий внимания багофикс все же есть - это исправление ошибки "After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted". То есть, снова возрождался баг о том, что данные, резервируемые с использованием трекинга изменившихся блоков CBT (а это используют все системы резервного копирования), могут оказаться поврежденными.

Напомним, что прошлый апдейт пакета (vSphere 6.7 Update 3a) также не содержал существенных обновлений.

Скачать компоненты платформы VMware vSphere 6.7 Update 3b можно по этой ссылке.